Identifying dynamic groups

ABSTRACT

Technology is disclosed for identifying dynamic groups that correspond to a user of a system. A system partitions a set of dynamic groups into multiple test sets of dynamic groups. The system selects a test set and determines whether the user corresponds to the test set. In one implementation, the system combines the filters for the dynamic groups in each test set into a single test set filter. The test set filter is satisfied if the filter of any dynamic group in the test set is satisfied. This allows the system to perform a single comparison between the resulting test set filter and the user&#39;s profile to determine whether the user is a member of any dynamic group in the test set. If the user is not a member of any dynamic group in the test set, the system eliminates all of the test set&#39;s dynamic groups from consideration, based on the single comparison. Otherwise, the dynamic groups in the test set remain in a list of groups that may include the user. This process is repeated for each test set. After each test set has been evaluated, new test sets are repeatedly generated and evaluated in the above-described fashion using the dynamic groups that are still in consideration. In each iteration, each test set contains fewer dynamic groups. This continues until each test set only contains one dynamic group. After performing an iteration with each test set containing one dynamic group, the only remaining dynamic groups are the ones that include the user as a member.

This application is a continuation of U.S. patent application Ser. No.10/328,920 filed Dec. 23, 2002 by Delaney et al. and entitled“Identifying Dynamic Groups,” which claims the benefit of U.S.Provisional Application No. 60/395,152, “Access and Identity System,”filed on Jul. 11, 2002. Both of these applications are incorporatedherein by reference.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is related to U.S. patent application Ser. No.09/998,926, entitled “Determining Group Membership,” filed on Nov. 30,2001, and incorporated herein by reference in its entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention is directed to technology for identifying dynamicgroups that correspond to an entity, such as a user.

2. Description of the Related Art

With the growth of the Internet, the use of networks and otherinformation technologies, Identity Systems have become more popular. Ingeneral, an Identity System provides for the creation, removal, editingand other managing of identity information stored in various types ofdata stores. The identity information pertains to users, groups,organizations and/or things. For each entry in the data store, a set ofattributes are stored. For example, the attributes stored for a user mayinclude a name, address, employee number, telephone number, emailaddress, user ID and password. The Identity System can also manageaccess privileges that govern what an entity can view, create, modify oruse in the Identity System. Often, this management of access privilegesis based on one or more specific attributes, membership in a groupand/or association with an organization.

In many instances it is useful to identify the groups corresponding to auser. For example, an employee at a company may want to know all thegroups that include the employee as a member. Ideally, an IdentitySystem would be able to create a list of such groups for the employee.Providing such a list can be very computation intensive when all or someof the groups are dynamic groups—groups that identify membership with afilter instead of a static membership list. One implementation of afilter or rule specifies attribute values an employee profile mustcontain in order for the employee to qualify as a group member.

The Identity System may need to determine a user's dynamic groups bycomparing the user's profile to each dynamic group's filter, even thoughusers typically belong to much less than all of the groups. Thiscomparison can consume substantial processing time and memory bandwidth.In a directory based Identity System, each dynamic group comparisonrequires a separate directory access of the user's profile. It would bedesirable for a user's corresponding dynamic groups to be identifiedmore efficiently in some circumstances.

In order to avoid the identification of dynamic groups, some systemsmaintain dynamic filters for group membership in user profiles. Thegroup filter in a user profile dynamically defines one or more groupsthat include the user. In this scheme, all of a user's groups can beidentified by a single directory access of the user profile. Thissolution, however, does not allow system administrators to organizeusers through the implementation of group profiles. This can be asignificant drawback. The use of dynamic group profiles is a popularscheme for grouping large numbers of entities, such as users. Withoutthe use of dynamic groups, the creation of a new group may require theupdating of each group member's profile.

Some Identity System users also employ an Access Systems. An AccessSystem provides for the authentication and authorization of usersattempting to access resources. For efficiency purposes, there is anadvantage to integrating the Identity System and the Access System. Forexample, both systems may utilize a single set of group objects thatidentify user membership in various groups. Additionally, integratingthe Identity System and the Access System allows for single-sign-onfunctionality across multiple resources. Thus, there is also a need toefficiently support the identification of a user's dynamic groups forAccess Systems and integrated Identity/Access Systems. Systems otherthan Identity and Access Systems can also benefit from the efficientidentification of a user's groups.

SUMMARY OF THE INVENTION

The present invention, roughly described, pertains to technology foridentifying dynamic groups that correspond to a user. In many instances,users and other entities only belong to a small percentage of thedynamic groups being maintained in a system. Embodiments of the presentinvention reduce the number of data accesses and dynamic group filtercomparisons under these circumstances.

In one embodiment, an Identity System partitions a set of dynamic groupsinto multiple test sets. Each test set contains a subset of the dynamicgroups. The system selects a test set and determines whether a usercorresponds to the test set. In one example, the system determineswhether the attributes in the user's profile meets the criteriaestablished by any of the filters for the dynamic groups in the testset.

One implementation of the Identity System combines the filters for eachdynamic group in each test set into a single filter that represents eachdynamic group filter's criteria. For example, the test set filter is alogical OR of the test set's dynamic group filters in one embodiment.This enables the system to perform a single comparison between theresulting test set filter and the user profile—determining whether theuser is a member of any dynamic group in the test set. If the user isnot a member of any dynamic group in the test set, the system eliminatesall of the test set's dynamic groups from consideration, based on thesingle comparison. Otherwise, the dynamic groups in the test set remainin a list of groups that may include the user. This process is repeatedfor each test set.

In one embodiment, user profiles and dynamic group profiles aremaintained in a Lightweight Directory Access Protocol (“LDAP”)directory. The system implements the above-described comparison as abase object search of the entity's profile using the test set filter.This allows a single directory access to yield the simultaneouselimination of multiple dynamic groups that do not include the user, asopposed to requiring separate directory accesses for each dynamic group.In alternate embodiments, protocols other than LDAP can be employed.

After each test set has been evaluated, the remaining list of dynamicgroups is partitioned again into a new set of test sets. Each new testset contains a subset of the remaining dynamic groups. In oneembodiment, the new test sets contain half as many dynamic groups as theprevious set of test sets contained. Each of the new test sets isevaluated as described above. After the evaluation, new test sets arerepeatedly generated and evaluated in the above-described fashion, untileach test set only contains one dynamic group. After performing aniteration with each test set containing one dynamic group, the onlyremaining dynamic groups are the ones that include the entity as amember.

In an alternate implementation, the system drills down into each testset after the initial partitioning. For each test set, the systemremoves each dynamic group that does not include the user. In drillingdown, the system repeatedly partitions the test set and forms a filterfor each partition that represents all of the dynamic group filters inthe partition. The system uses these filters to determine whether theuser's profile satisfies any of the dynamic group filters in thepartition, similar to the process above.

The present invention can be accomplished using hardware, software, or acombination of both hardware and software. The software used for thepresent invention is stored on one or more processor readable storagemedia including hard disk drives, CD-ROMs, DVDs, optical disks, floppydisks, tape drives, RAM, ROM or other suitable storage devices. Inalternative embodiments, some or all of the software can be replaced bydedicated hardware including custom integrated circuits, gate arrays,FPGAs, PLDs, and special purpose computers. In one embodiment, softwareimplementing the present invention is used to program one or moreprocessors. The processors can be in communication with one or morestorage devices, peripherals and/or communication interfaces.

These and other objects and advantages of the present invention willappear more clearly from the following description in which thepreferred embodiment of the invention has been set forth in conjunctionwith the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram depicting the components of one embodiment ofthe present invention.

FIG. 2 is a flow chart describing one embodiment of a process forauthenticating and authorizing.

FIG. 3 is an example of a directory tree structure.

FIG. 4 is a block diagram depicting the User Manager.

FIG. 5 is a block diagram depicting the Group Manager.

FIG. 6 is a block diagram depicting the Organization Manager.

FIG. 7 is a flow chart describing one embodiment of a process forviewing all groups corresponding to an entity.

FIG. 8 is a flow chart describing a second embodiment of a process forviewing all groups corresponding to an entity.

FIG. 9 is a flow chart describing one embodiment of a process foridentifying dynamic groups corresponding to an entity.

FIG. 10 is a flow chart describing one embodiment of a process foridentifying a set of dynamic groups.

FIG. 11 is a flow chart describing one embodiment of a process fordetermining whether an entity corresponds to a test set including atleast one dynamic group.

FIG. 12 is a flow chart describing an alternate embodiment of a processfor identifying dynamic groups corresponding to an entity.

DETAILED DESCRIPTION

FIG. 1 depicts an example of an access management system that providesidentity management services and/or access management services for anetwork. The identity management portion of the system (hereinafter “theIdentity System”) manages identity profiles, while the access managementportion of the system (hereinafter “the Access System”) providessecurity for resources across one or more Web Servers (or othercomponents). A key feature of one embodiment of this system is thecentralization of the repositories for policies and identity profiles,while decentralizing their administration. That is, one embodiment ofthe system centralizes the policy and identity repositories by buildingthem on a directory service technology. The system decentralizes theiradministration by hierarchy delegating administrative roles. Althoughthe system of FIG. 1 includes an Identity System and an Access System,other embodiments may only include an Identity System or only include anAccess System.

FIG. 1 is a block diagram depicting one embodiment for deploying anintegrated Identity System and Access System. FIG. 1 shows web browsers12 and 14 accessing Web Server 18 and/or Web Server 20 via network 16.One example of a network is the Internet. In one embodiment, webbrowsers 12 and 14 are standard web browsers known in the art running onany suitable type of computer. FIG. 1 depicts web browsers 12 and 14communicating with Web Server 18 and Web Server 20 using HTTP over theInternet; however, other protocols and networks can also be used.

Web Server 18 is a standard Web Server known in the art and provides anend user with access to various resources via network 16. One embodimentincludes two firewalls. A first firewall (see dotted lines) is connectedbetween network 16 and Web Server 18. A second firewall (see dottedlines) is connected between Web Servers 16 and 18 and Access Server34/Identity Server 40.

FIG. 1 shows two types of resources: resource 22 and resource 24.Resource 22 is external to Web Server 18 but can be accessed through WebServer 18. Resource 24 is located on Web Server 18. A resource can beanything that is possible to address with a uniform resource locator(URL, see RFC 1738). A resource can include a web page, softwareapplication, file, database, directory, data unit, etc. In oneembodiment, a resource is anything accessible to a user via a network.The network could be the Internet, a LAN, a WAN, or any other type ofnetwork.

FIG. 1 shows Web Server 18 including Web Gate 28, which is a softwaremodule. In one embodiment, Web Gate 28 is a plug-in to Web Server 18.Web Gate 28 communicates with Access Server 34. Access Server 34communicates with Directory 36.

The Access System includes Access Server 34, Web Gate 28, and Directory36. Access Server 34 provides authentication, authorization, auditingand logging services. It further provides for identity profiles to beused across multiple domains and for access based on a single web-basedauthentication (sign-on). Web Gate 28 acts as an interface between WebServer 18 and Access Server 34. Web Gate 28 intercepts requests fromusers for resources 22 and 24, and authorizes them via Access Server 34.Access Server 34 is able to provide centralized authentication,authorization, and auditing services for resources hosted on oravailable to Web Server 18 and other Web Servers.

The Identity System includes Web Pass 38, Identity Server 40 andDirectory 36. Identity Server 40 manages identity profiles. An identityprofile is a set of information associated with a particular entity(e.g. user, group, organization, etc.). The data elements of theidentity profile are called attributes. An attribute may include a name,a value and access criteria. The Identity Server includes three mainapplications, which effectively handle the identity profiles andprivileges of the user population: User Manager 42, Group Manager 44,and Organization Manager 46. User Manager 42 manages the identityprofiles for individual users. Group Manager 44 manages identityprofiles for groups. Organization Manager 46 manages identity profilesfor organizations. Identity Server 40 also includes Publisher 48, anapplication that enables entities to quickly locate and graphically viewinformation stored by Directory 36. In one embodiment, Web Pass 38 is aWeb Server plug-in that sends information back and forth betweenIdentity Server 40 and the Web Server 20, creating a three-tierarchitecture. The Identity System also provides a Certificate ProcessingServer (not shown in FIG. 1) for managing digital certificates.

User Manager 42 handles the functions related to user identities andaccess privileges, including creation and deletion of user identityprofiles, modification of user identity profile data, determination ofaccess privileges, and credentials management of both passwords anddigital certificates. With User Manager 42, the create, delete, andmodify functions of user identity management can be set as flexible,multi-step workflows. Each business can customize its own approval,setup, and management processes and have multiple processes fordifferent kinds of users.

Group Manager 44 allows entities to create, delete and manage groups ofusers who need identical access privileges to a specific resource or setof resources. Managing and controlling privileges for a group of relatedpeople—rather than handling their needs individually—yield valuableeconomies of scale. Group Manager 44 meets a wide range of e-businessneeds: easy creation, maintenance, and deletion of permanent and ad hocgroups of users who may be allowed or denied access to particularresources; modification and adaptation of groups and their accessprivileges with minimal disruption to the directory server's underlyingschema; efficient addition and deletion of users from establishedgroups; and delegation of administrative responsibility for groupmembership and subscription requests and approvals.

With Group Manager 44, companies (or other entities) can allowindividual users to do the following: (1) self-subscribe to andunsubscribe from groups, (2) view the groups that they are eligible tojoin or have joined, and (3) request subscription to groups that haveaccess to the applications they need. Multi-step workflows can thendefine which users must obtain approval before being added to a groupand which can be added instantly. Group Manager 44 also letsorganizations form dynamic groups specified by an LDAP filter. Theability to create and use dynamic groups is extremely valuable becauseit eliminates the administrative headache of continually keepingindividual, static membership up-to-date. With dynamic group managementfeatures, users can be automatically added or removed if they meet thecriteria specified by the LDAP filter. Dynamic groups also greatlyenhance security since changes in user identities that disqualifysomeone from membership in a group are automatically reflected in thedynamic group membership.

The third application in the Identity System, Organization Manager 46,streamlines the management of large numbers of organizations within ane-business network, including partners, suppliers, or even majorinternal organizations such as sales offices and business units. Certaininfrastructure security and management operations are best handled—orcan only be handled—at the highest organizational unit level rather thanat the individual or group level. Like User Manager and Group Manager,this application relies on multi-step workflow and delegationcapabilities. Organization Manager handles the following administrativetasks: (1) organization lifecycle management, whereby companies cancreate, register, and delete organizations in their systems usingcustomizable workflows; (2) maintenance of organization profiles on anattribute-by-attribute basis through self-service, delegatedadministration and system-initiated activities; (3) organizationself-registration, whereby organizations such as business partners,customers and suppliers can self-generate a request to be added to thee-business network; and (4) creation of reusable rules and processesthrough multi-step workflows.

The various components of FIG. 1 can be implemented by software runningon computing devices. Many different types of computing devices can beused, including servers, mainframes, minicomputers, personal computers,mobile computing devices, etc. Typically, such computing devices willhave one or more processors that are programmed by code that is storedin one or more processor readable storage devices. The one or moreprocessors are in communication with the processor readable storagedevices, peripherals (e.g. keyboards, monitors, pointing devices,printers, etc.) and communication interfaces (e.g. network interfaces,modems, wireless transmitters/receivers, etc.).

The system of FIG. 1 is scalable. There can be many Web Servers, manyAccess Servers, and many Identity Servers. In one embodiment, Directory36 is a Directory Server and communicates with other servers/modulesusing LDAP or LDAP over SSL. In other embodiments, Directory 36 canimplement other protocols or can be other types of data repositories(e.g. relational database using SQL, etc.). Many variations of thesystem of FIG. 1 can be used with the present invention. For example,instead of accessing the system with a web browser, an API can be used.Alternatively, portions of functionality of the system at FIG. 1 can beseparated into independent programs that can be accessed with a URL.

To understand how the system of FIG. 1 protects a resource, firstconsider the operation of unprotected resources. With a typicalunprotected resource, end users cause their browsers to send a requestto a Web Server. The request is usually an HTTP request, which includesa URL. The Web Server then translates, or maps, the URL into a filesystem's name space and locates the matching resource. The resource isthen returned to the browser.

With the system of FIG. 1 deployed, Web Server 18 (enabled by Web Gate28, Access Server 34, and Directory 36) can make informed decisionsbased on default and/or specific rules about whether to return requestedresources to an end user. The rules are evaluated based on the enduser's identity profile, which is managed by the Identity System. In oneembodiment of the present invention, the general method proceeds asfollows. An end user enters a URL or an identification of a requestedresource residing in a protected policy domain. The user's browser sendsthe URL as part of an HTTP request to Web Server 18. Web Gate 28intercepts the request. If the end user has not already beenauthenticated, Web Gate 28 causes Web Server 18 to issue a challenge tothe browser for log-on information.

The received log-on information is passed back to Web Server 18 and onto Web Gate 28. Web Gate 28 in turn makes an authentication request toAccess Server 34, which determines whether the user's supplied log-oninformation is authentic or not. Access Server 34 performs theauthentication by accessing attributes of the user's identity profileand the resource's authentication criteria stored on Directory 36. Ifthe user's supplied log-on information satisfies the authenticationcriteria, the process flows as described below; otherwise, the end useris notified that access to the requested resource is denied and theprocess halts.

After authenticating the user, Web Gate 28 queries Access Server 34about whether the user is authorized to access the resource requested.Access Server 34 in turn queries Directory 36 for the appropriateauthorization criteria for the requested resource. Access Server 34retrieves the authorization criteria for the resource and answers WebGate 28's authorization query, based on the resource's authorizationcriteria and the user's identity profile. If the user is authorized, theuser is granted access to the resource; otherwise, the user's request isdenied. Various alternatives to the above described flow are also withinthe spirit and scope of the present invention.

Authentication and Authorization decisions are based on policy domainsand policies. A policy domain is a logical grouping of Web Server hostID's, host names, URL prefixes, and rules. Host names and URL prefixesspecify the course-grain portion of the web name space a given policydomain protects. Rules specify the conditions in which access torequested resources is allowed or denied, and to which end users theseconditions apply. Policy domains contain two levels of rules: firstlevel default rules and second level rules contained in policies. Firstlevel default rules apply to any resource in a policy domain notassociated with a policy.

A policy is a grouping of a URL pattern, resource type, operation type(such as a request method), and policy rules. These policy rules are thesecond level rules described above. Policies are always attached to apolicy domain and specify the fine-grain portion of a web name spacethat a policy protects. In practice, the host names and URL prefixesfrom the policy's policy domain are logically concatenated with thepolicy's URL pattern. The resulting overall pattern is compared to theincoming URL. If there is a match, then the policy's various rules areevaluated to determine whether the request should be allowed or denied;if there is not a match, then default policy domain rules are used.

FIG. 2 provides a flow chart for one embodiment of a method forauthenticating and authorizing. A user's browser 12 requests aweb-enabled resource 22 or 24 (step 50). The request is intercepted byWeb Gate 28 (step 52). The method then determines whether the requestedresource is protected by an authentication and/or authorization rule(step 53). If the resource is not protected, then access is granted tothe requested resource (step 95). If the requested resource isprotected, however, the method proceeds to step 54. If the user waspreviously authenticated for a protected resource in the same domain, avalid authentication cookie is passed by browser 12 with the request instep 50. The authentication cookie is intercepted by Web Gate 28 in step52. If a valid cookie is received (step 54), the method attempts toauthorize the user (step 56). If no valid authentication cookie isreceived (step 54), the method attempts to authenticate the user for therequested resource (step 60).

If the user successfully authenticates for the requested resource (step62), then the method proceeds to step 74. Otherwise, the unsuccessfulauthentication is logged (step 64). After step 64, the system performsauthentication failure actions and Web Gate 28 denies the user access tothe requested resource (step 66). In step 74, the successfulauthentication of the user for the resource is logged. The method thenperforms authentication success actions (step 76). In response to thesuccessful authentication, Web Gate 28 then passes a validauthentication cookie to browser 12 (step 80), which stores the cookie.After passing the cookie in step 80, the system attempts to authorize(step 56).

In step 56, the method determines whether the user is authorized toaccess the requested resource. If the user is authorized (step 90), themethod proceeds to step 92. Otherwise, the unsuccessful authorization islogged (step 96). After step 96, the method performs authorizationfailure actions (step 98) and Web Gate 28 denies the user access to therequested resource. If authorization is successful (step 90), then thesuccessful authorization of the user is logged (step 92). Authorizationsuccess actions are performed in step 94. The user is granted access tothe requested resource (step 95). In one embodiment of step 95, some orall of HTTP request information is provided to the resource. In one ormore scenarios, the resource being accessed is the Identity System.

More information about authorization, authentication, an Access Systemand an Identity System can be found in U.S. patent application Ser. No.09/998,926, “Determining Group Membership,” filed on Nov. 30, 2001,which is incorporated herein by reference in its entirety.

Both the Identity System and the Access System make use of Directory 36.The basic unit of information store in Directory 36 is called an entryor identity profile, which is a collection of information about anobject. The information in an entry often describes a real-world objectsuch as a person, but this is not required. A typical directory includesmany entries that correspond to people, departments, groups and otherobjects in the organization served by the directory. An entry iscomposed of a set of attributes, each of which describes one particulartrait of the object Each attribute has a type, one or more values, andassociated access criteria. The type describes the kind of informationcontained in the attribute, and the value contains the actual data.

An entry in the directory has a set of attributes that are required anda set of attributes that are allowed. For example, an entry describing aperson is required to have a cn (common name) attribute and an sn(surname) attribute. One example of an allowed attribute may be anickname. Any attribute not explicitly required or allowed isprohibited.

Examples of attributes stored in a user identity profile include: firstname, middle name, last name, title, email address, telephone number,fax number, mobile telephone number, pager number, pager email address,identification of work facility, building number, floor number, mailingaddress, room number, mail stop, manager, direct reports, administrator,organization that the user works for, department number, department URL,skills, projects currently working on, past projects, home telephone,home address, birthday, previous employers and anything else desired tobe stored by an administrator. Examples of attributes stored in a groupidentity profile include: owner, name, description, static members,dynamic member rule, subscription policies, etc. Examples of attributesstored in a user organization identity profile include: owner, name,description, business category, address, country, etc. In otherembodiments, less or more than the above-listed information is stored.

FIG. 3 depicts an exemplar directory tree that can be stored inDirectory 36. Each node on the tree is an entry in the directorystructure that includes an identity profile. In one embodiment, theentity can be a user, group or organization. Node 230 is the highestnode on the tree and represents an entity responsible for the directorystructure. In one example, an entity may set up an Extranet and grantExtranet access to many different companies. The entity setting up theExtranet is node 130. Each of the companies with Extranet access wouldhave a node at a level below node 130. For example, company A (node 132)and company B (node 134) are directly below node 130. Each company maybe broken up into organizations. The organizations could be departmentsin the company or logical groups to help manage the users. For example,FIG. 3 shows company A broken up into two organizations: organization Awith node 136 and organization B with node 138. Company B is shown to bebroken up into two organizations: organization C with node 140 andorganization D with node 142. FIG. 3 shows organization A having two endusers: employee 1 with node 150 and employee 2 with node 152.Organization B is shown with two end users: employee 3 with node 154 andemployee 4 with node 156. Organization C is shown with two end users:employee 5 with node 158 and employee 6 with node 160. Organization D isshown with two end users: employee 7 with node 162 and employee 8 withnode 164.

Each entity has a distinguished name (DN), which uniquely identifies thenode. In one embodiment, each entry also has a relative name, which isdifferent from all other relative names on the same level of thehierarchy. In one implementation, the distinguished name (DN) comprisesa union of the relative names up the tree. For example, thedistinguished name of employee 1 (node 150) is

DN=CN=Empl, OU=OrgA, O=CompanyA, DC=entity,

where:

-   -   DC=Domain Component    -   O=Organization    -   OU=Organizational Unit    -   CN=common name.

FIG. 3 shows a hierarchical tree. Some organizations employ fat or flattrees for ease of maintenance. A flat directory tree may be a directoryinformation tree that does not have any hierarchy or a shallow treestructure with a higher ratio of leaves to total nodes. A fat directorytree is a tree that has a large number of nodes at any given level in adirectory information tree. One advantage of a fat or flat tree is usermaintenance. For example, if an employee moves to a new group, the nodemust be moved to a new container if the tree is not flat or fat. Bymoving the node to a new container, the distinguished name for the nodechanges and all certificates become void. One drawback of flat or fattrees is that the organization loses the benefits of having a logicaldirectory structure mirrored in the physical directory structure, suchas using the physical directory structure to determine who has access towhich nodes. To remedy this, the Identity System includes partitionsupport for fat and flat tree directories using filters. From aconfiguration page, an attribute can be configured to be accessible(read, modify, etc.,) based on a two part filter. The first component inthe filter identifies a top node in the directory. The filter will onlyapply to those entities at or below that top node. The second componentof the filter is an LDAP filter which defines who can access theattribute. This two component filter can be applied on an attribute byattribute basis.

There are many ways for an entity to access and use the Identity System.In one embodiment, the entity can access the Identity System's servicesusing a browser. In other embodiments, XML documents and API's can beused to access the services of the Identity System. For example, anentity can use a browser by pointing the browser to Identity Server 40.The user will then be provided with a login page to enter the user's ID,password, type of user and application requested (optional). Uponfilling out that information, the user will be authenticated andauthorized (by the Access System) to use the Identity System.Alternatively, the Access System can be bypassed (or there may be noAccess System) and the Identity System authenticates the user.

As described above, the Identity System of FIG. 1 includes User Manager42, Group Manager 44 and Organization Manager 46. User Manager 42manages identity profiles for users. Group Manager 44 manages identityprofiles for groups. Organization Manager 46 manages identity profilesfor organizations. Each of these components will now be described inmore detail.

FIG. 4 graphically depicts the various services provided by User Manager42. Each of these services can be accessed from a User Manager homepage. For example, in one embodiment, the home page will includeapplication selector 202, search tool 204, My Identity tab 206, CreateUser Identity tab 208, Deactivate User Identity tab 210, SubstituteRights tab 212, Requests tab 214 and Configure tab 216. Applicationselector 202 lets the user change applications from the User Manager toeither the Group Manager, Object Manager or Publisher. In oneembodiment, application selector 202 is a drop down menu. Search tool204 enables a user to provide search information in order to search thedirectory for a set of one or more user identity profiles.

By selecting My Identity tab 206, a user is provided with theinformation stored in that user's identity profile. Create User Identitytab 208 allows a user with the appropriate privileges to create a newuser identity profile (e.g. with a workflow). Deactivate User Identitytab 210 allows a user with proper privileges to remove an identityprofile from the directory. Substitute Rights tab 212 allows the user toindicate who can proxy that user and allows the user to be a proxy forsomeone else. Request tab 214 allows a user to monitor workflows thatare in progress or recently completed. Depending on the user'sprivileges, by selecting request tab 214, the user can see all workflowsthat involve that user, that are started by that user, that affect thatuser or that the user has privileges to view. Request tab 214 willindicate workflows for which there is an outstanding action to be doneby the current user. The user can select that workflow and perform thetask.

Configure tab 216 allows a user to configure various options for UserManger 42. The user must have sufficient privileges to access Configuretab 216. The user can perform attribute access control, delegateadministration, define workflows and set the search base. Attributeaccess control includes controlling who has view and modify permissionsfor each attribute. Attributes can be set at any and all levels in anorganization. The configuration also allows the specification of ane-mail notification list when a change to an attribute is requested.Delegation administration includes delegating administrative tasks tolocal administrators. An entity can choose what rights to delegate, whomto delegate to, and the scope to delegate. Workflow definition includesdefining workflows for a particular organization, defining who will beresponsible for the workflow actions and/or defining who will bereceiving notifications for the workflow actions. Setting the searchbase includes setting the search base for a particular organization,person or set of persons. This will localize access to ensure security.

FIG. 5 depicts the various services provided by Group Manager 44. Oncean entity is at the Group Manager home page, the entity can accessapplication selector 230, search tool 232, My Groups tab 234, CreateGroups tab 236, Request tab 238, Manage Subscriptions tab 239, Configuretab 240, and Manage Members tab 241. My Groups tab 234 indicates thegroups of which the entity is a member. By selecting any of the groupsidentified by My Groups tab 234 or Search Tool 232, the user will beprovided with the identity profile page for that particular group. Fromthe profile page, the group can be modified or deleted. Create groupstab 236 allows the user to create a new group. Request tab 238 providesthe user with access to currently pending and recently finishedworkflows that involve groups. Configure tab 240 allows the user toconfigure various information about groups in the Group Manager. Whileviewing the identity profile for a group, the entity can modify thatprofile if the entity has appropriate privileges.

Configure tab 240 allows an entity to provide attribute access control,delegate rights, define workflows and expand dynamic groups. Attributeaccess control includes controlling who has view and modify permissionsfor each attribute in group identity profiles. Additionally, e-mailnotification lists can be created which are used to notify entities whena change to an attribute is requested. Administration tasks can bedelegated to local administrators. An entity can choose what rights todelegate, who to delegate to, and what the scope of the delegation is.Workflow definition includes defining the workflows for a particulargroup. This includes defining who is responsible for the workflowactions and who will be receiving notifications for workflow actions.Note that some of the tabs and services may not be available to allentities, depending upon the privileges of those entities. ManageSubscriptions tab 239 allows users to subscribe to groups or unsubscribefrom groups. Manage Members tab 241 allows users to view, add, remove,and search members of a group.

FIG. 6 depicts the services provided by Organization Manager 46.Organization manager 46 provides functionality to create, modify, deleteand manage organizational objects. From the home page for OrganizationManager 46, a user is provided with application selector 242, searchtool 244, Create Organizational Profile tab 246, Request tab 248 andConfigure tab 250. Application selector 242 allows the user to select adifferent application to access. Search tool 244 provides a user withthe ability to enter search terms in order to search for one or moreorganizational objects. After performing a search, the user will beprovided with a list of organizational objects meeting the searchrequirements. User can select any of these objects to view, modify ordelete, if the user has sufficient privileges.

Create Organizational Profile tab 246 allows a user to create neworganizational objects, if the user has sufficient privileges. Requesttab 248 allows a user to access pending workflows and workflows thathave recently been finished that relate to organizational objects.Access to Request tab 248 can be restricted and/or limited dependingupon users privileges. If a user has a step to perform for a workflow,it will be indicated by Request tab 248.

Configure tab 250 allows the entity to perform attribute access control,delegate administration, define workflows and define container limits.Attribute access control includes controlling who has view and modifypermissions for each attribute of an organizational identity profile. Inaddition, an entity can specify an e-mail notification list when achange to an attribute is requested. Delegating administration includesdelegating administrative tasks to local administrators. An entity canchoose what rights to delegate, whom to delegate to, and the scope ofthe delegation. Workflow definition includes defining the workflows fora particular organization, including who will be responsible for theworkflow actions and who will be receiving notifications for theworkflow. Container limits includes controlling how many objects can becreated in an organization. This would also include defining who will bereceiving notifications that a container limit has been met, has beenviolated or is close to being met.

Looking back at FIG. 5, one of the services provided by Group Manager 44is to the ability to view a list of all groups of which a user is amember. A user can be a static member of a group, a dynamic member of agroup or a nested member of a group. A user is a static member if theuser is explicitly listed as a member. For example, the user can beidentified in a membership attribute of the group identity profile. Auser is a dynamic member if the user's identity profile satisfies theLDAP rule that specifies the group's dynamic membership. The LDAP ruleis stored in an attribute of the group identity profile. A user is anested member of Group A if the user is a member of Group B and Group Bis a member of Group A. The number of levels of nesting is not limited.A nested member of a group receives the privileges of being a member,including receiving access to resources available to the group.

When a user selects the My Groups tab 234, the user is provided with alist of the groups for which the user is a static member, dynamic memberor nested member. In one embodiment, My Groups tab 234 visualizes thecontainment relationship of all groups in which the user is a member.This relationship is displayed as a tree on its side, with the roots onthe left and the leaves on the right. The display allows the user totunnel down from a particular group to display the groups contained in(e.g. that are a member of) that group, and so on.

FIG. 7 is a flowchart describing one embodiment of a process fordetermining all the groups of which a user is a member, including staticmembership, dynamic membership and nested membership. The process can beused to build a tree structure in which the nodes are groups thatcontain the user as a member. The leaf nodes of the tree are thosegroups in which the user is a static or dynamic member. All other nodesare groups in which the user is a nested member. The process of FIG. 7assumes the following:

-   -   Let u denote the target user;    -   Let g denote a single group;    -   Let G denote a set of groups, where the g_(i) denotes the i^(th)        group in the set;    -   Let G_(s) denote the set of groups in which u is a static        member;    -   Let G_(d) denote the set of groups in which u is a dynamic        member; and    -   Let G_(t) denote the set of groups in which each g_(i) has a        reference to each of its containing groups.

The process of FIG. 7 starts at step 300 when a user requests to viewgroups of which the user is a member. One example of performing step 310is the selection of My Groups tab 234 (see FIG. 5). The systemdetermines all groups of which the user is a static member (step 302).Each group identity profile has an attribute defining static membership.The system determines all groups for which the user is specificallylisted in the static membership attribute. The system determines allgroups of which the user is a dynamic member (step 304). A group canhave an attribute that defines a dynamic membership in terms of an LDAPfilter/rule. In one embodiment, the system compares the user's identityprofile with the LDAP filter for each group to determine which filtersare satisfied by the user's identity profile. Those LDAP filters thatare satisfied are groups in which the user is a dynamic member. Furtherdetails regarding the identification of dynamic groups for a user arepresented below.

The set of groups that the user is a static member of and the set ofgroups that the user is a dynamic member of are combined to determinethe set of groups in which the user is either a dynamic or static member(step 306). The final set of groups G_(t) is initialized to the set ofgroups in which the user is either a static member or dynamic member(step 308). For each group in which the user is a static or dynamicmember, the system calls the function Find_Containing_Groups (step 310).The results of the function are added to the set G_(t). The resultingset G_(t) is reported as an identification of all the groups in whichthe user is either a static, dynamic or nested member (step 314). Theresulting set can be reported in various ways including reporting thegroups in a GUI for the user (e.g. a tree on its side), reporting thegroups to the user in a non-graphical format, storing a list of thegroups in a file, providing identifications of the groups to anotherprocess, etc. In one example, the Access System requests that theIdentity System determine a user's groups so that the Access System canauthorize a user to access a resource based on membership in aparticular group.

The function Find_Containing_Groups (shown as step 312) includes threesub-steps. In the first sub-step (substep 1 in step 312), the systemfinds all groups that contain g_(j) as a member. These are thecontaining groups of g_(j). In the second sub-step, the system iteratesover the set of containing groups. In sub-step 2.i. (step 312), thesystem marks g_(i) as a containing group g_(j). The markings areprovided in order to graphically show the nesting relationship in MyGroups tab 234. In sub-step 2.ii. (step 312), the system recursivelyfinds the containing groups of g_(i). In sub-step 3 (step 312), thesystem returns the closure of the set of containing groups.

FIG. 8 is a second embodiment of a process for determining the groups inwhich the user is a member. The process of FIG. 8 is a more optimizedmethod than FIG. 7. The process of FIG. 8 utilizes the followingassumptions:

-   -   Let u denote the target user;    -   Let g denote a single group;    -   Let G denote a set of groups where g_(i) denotes the i^(th)        group in the set;    -   Let G_(s) denote the set of groups in which u is a static        member;    -   Let G_(d) denote the set of groups in which u is a dynamic        member;    -   Let G_(ni) denote the set of groups in which u is a nested        member, where i denotes the i^(th) level of nesting;    -   Let G_(n) denote the set of G_(ni) where i is the i^(th) set of        groups;    -   Let G_(c) be a set of groups, where g_(j) denotes the j^(th)        group in the set; and    -   Let G_(m) be a set of groups, where g_(k) denotes the k^(th)        group in the set, such that for all g_(k), there exists g_(j)        such that g_(k) is a static member of g_(j).

In step 340 of FIG. 8, the system receives a request to view groups ofwhich a user is a member. One example of performing step 340 is the userselecting My Groups tab 234. The system determines the set of groupsG_(s) in which the user is a static member (step 342). The systemdetermines the set of groups G_(d) in which the user is a dynamic member(step 344). The variable i is initialized to nesting level 0 (step 346).G_(ni) is initialized to be the union of G_(s) and G_(d) (step 348). Thesystem iterates until the set of groups for the i^(th) level of nestingis empty, finding the (i+1^(th)) set of groups which contain groups thathave a static member that is in the i^(th) set of groups (step 350).

The system iterates over the set of groups in G_(n) (step 352). In stepa, G_(c) is set to G_(ni+1). In step b, G_(m) is assigned to equalG_(ni). In step c, the system iterates over the containing set of groupsG_(c). In step d, the system iterates over the contained set of groupsG_(m). In step e, the system determines if group g_(k) (the containedgroup under consideration) is a static member of the group g_(j) (thecontaining group under consideration). In step f, the containing groupg_(j) is marked as a containing group of g_(k), if g_(k) is a staticmember of g_(j). The system iterates over the set of G_(ni), adding eachset of groups to the final set G_(t) (step 354). The resulting set ofgroups G_(t) is reported back to the requester (step 356).

FIG. 9 is a flowchart describing one embodiment of a process foridentifying all of the dynamic groups that include a user (step 304,FIG. 7 and step 344, FIG. 8). This process is described with referenceto the Identity System, but in alternate embodiments, the process can becarried out by the Access System, an integrated Access System andIdentity System, or another type of system. In one embodiment, the useris represented in the Identity System by a user profile, which may alsobe referred to as a user object. In further embodiments, dynamic groupsare identified for an entity other than a user. Embodiments of theinvention can also be implemented for dynamic profiles other than groupprofiles. For example, dynamic organization profiles can be employed. Inanother example, a role is defined by a dynamic profile, and the presentinvention is used to determine the roles that correspond to an entity,such as a user. An example role is a job type, such as manager.

The Identity System identifies a set of dynamic groups that have thepotential for including the user as a member (step 400). In oneimplementation, the set may include all dynamic groups accessible by theIdentity System. In alternate implementations, the identified set ofdynamic groups is a subset of all the dynamic groups accessible by theIdentity System. Greater details regarding the selection of a subset areprovided below. The Identity System sets a partition size (step 402).The partition size is less than the number of dynamic groups in the setof dynamic groups identified in step 400. In one example, the partitionsize is set to 20.

The Identity System partitions the set of dynamic groups into test sets(step 404). In one embodiment, the Identity System assigns each dynamicgroup to a test set, so that each test set contains the number ofdynamic groups specified by the partition size. For example, when thepartition size is 20, the Identity System partitions a set of 100dynamic groups into 5 test sets with each test set containing 20 dynamicgroups. If the set of dynamic groups cannot be evenly divided into testsets of the partition size, the Identity System can use various methodsfor resolving the dilemma. In one example, the Identity System providesfor all but one of the test sets to contain the number of dynamic groupsspecified by the partition size. The remaining one test set containsless than the partition size. For example, when the partition size is20, the Identity System partitions a set of 98 dynamic groups into 4test sets of 20 dynamic groups and 1 test set of 18 dynamic groups. Infurther embodiments, multiple test sets can have less than the partitionsize of dynamic groups. Alternatively, one or more test sets may havemore dynamic groups than specified by the partition size. In anotherembodiment, partitioning is not based on size. An alternate mechanism isemployed, such as filter similarity.

The Identity System selects one of the test sets (step 406) anddetermines whether the user corresponds to the test set (step 408). Inone implementation, the Identity System determines correspondence (step408) by determining whether the user satisfies the requirements of anyof the filters for the test set's dynamic groups. For example, theIdentity System determines whether the attributes in the user's profilemeet the requirements of any of the filters for the test set's dynamicgroups. In order to make this determination, the Identity System employsa test set filter in one embodiment. The test set filter is satisfied ifany of the filters from the test set's dynamic group are satisfied. Inone example, the test set filter is a logical OR of the filters for thedynamic groups in the test set.

Using a single test set filter is beneficial when the user and dynamicgroup profiles are maintained in a directory server. The Identity Systemevaluates the user's attributes through a single comparison access ofthe user's profile using the test set filter—eliminating the need toaccess the user profile for each dynamic group in the test set. Greaterdetails about determining whether the user corresponds to a test set(step 408) are provided below.

If the user does not correspond to the test set (step 408), the IdentitySystem removes the dynamic groups in the test set from the set ofdynamic groups identified in step 400 (step 410). Otherwise, theIdentity System does not alter the list of dynamic groups in theidentified set. The Identity System goes on to determine whether any ofthe test sets have not yet been selected (step 412). If an unselectedtest remains, another test set is selected (step 406) and theabove-described process is repeated. Otherwise, the Identity Systemdetermines whether to perform further partitioning (step 414). If not,the process is complete. Otherwise, the Identity System sets a newpartition size (step 402) and repeats the above-described process.

In one implementation, the Identity System proceeds with furtherpartitioning, unless the last partition size employed was 1. In thisimplementation, further partitioning causes the remaining dynamic groupsin the initial set to be partitioned again (step 404) using a newlyselected partition size. The new partition size is less than theprevious partition size in one embodiment. In one example, the partitionsize is half of the prior partition size. When the partition sizereaches a value of 1, the Identity System partitions each of theremaining dynamic groups into its own test set. As a result, thecorrespondence evaluation is step 408 and subsequent removal ofnon-corresponding dynamic groups in step 410 leave a final list ofdynamic groups. The final list of dynamic groups are all of the dynamicgroups from the initial set that include the user as a member.

FIG. 10 is a flow chart describing one embodiment of a process foridentifying a set of dynamic groups (step 400, FIG. 9). The IdentitySystem selects a dynamic group that is accessible by the Identity System(step 430). The Identity System determines whether the user's searchbaseis within the searchbase of the rule of the dynamic group (step 432). Inone such embodiment, the user and dynamic group profiles are maintainedin an LDAP directory server. In step 432, the Identity System determineswhether the distinguished name of the user has the potential for fallingwithin the directory tree path specified by the LDAP rule governing thedynamic group's membership. In LDAP implementations, the user'sdistinguished name is frequently maintained in a local memory, making itaccessible without the need for a directory server access. This canenable the elimination of many non-corresponding dynamic groups withoutthe need for multiple directory server accesses.

For example, the entity may be employee 1 (node 150) shown in FIG. 3.The Identity System determines whether the dynamic group's LDAP rule hasthe potential for accepting a user in Org A (node 136, FIG. 3) ofCompany A (node 132, FIG. 3). If so, the user searchbase falls withinthe searchbase of the rule of the dynamic group. If not, the usersearchbase is considered not to fall within the searchbase of the ruleof the dynamic group. As an example, if the dynamic group's filter onlycalls for users in Company B (node 134, FIG. 3), the user searchbase isconsidered not to fall within the searchbase of the rule of the dynamicgroup.

If the user searchbase is within the searchbase of the rule of thedynamic group, Identity System includes the dynamic group in the set ofdynamic groups identified in step 400 of FIG. 9 (step 434). Otherwise,the dynamic group is not added to the set. The Identity System goes onto determine whether any accessible dynamic groups have not yet beenselected (step 436). If all accessible dynamic groups have beenselected, the process is complete. Otherwise, a new dynamic group isselected and the process in FIG. 10 is repeated.

In an alternate embodiment, an LDAP directory is not employed. Variousother data management solutions can be implemented. For example, theLDAP directory server can be replaced by a relational database.

FIG. 11 is a flow chart describing one embodiment of a process fordetermining whether a user corresponds to a test set including at leastone dynamic group (step 408, FIG. 9). The process shown in FIG. 11 canbe employed in embodiments where the user and group profiles aremaintained in a directory server. The Identity System sets the matchingcriteria for the test set (step 450). In one implementation, thematching criteria is an LDAP rule with 3 components set by the IdentitySystem.

The 3 components include a filter, searchbase, and scope. The IdentitySystem sets the filter component, so that the filter is satisfied if thefilter of any dynamic group in the test set is satisfied. In oneimplementation, the test set's filter is a logical OR of the filtersfrom the test set's dynamic groups. The Identity System sets thesearchbase component to the distinguished name of the user and the scopeto base object. A base object scope is a standard LDAP scope thatrestricts searching to the identified searchbase. In alternateembodiments, the scope can be set differently, such as single level orwhole subtree. In further embodiments, LDAP is not employed. Forexample, a relational database can be implemented with matching criteriadefined by an SQL query.

After setting the matching criteria, the Identity System performs asearch of the directory server based on the matching criteria from step450 (step 452). In the LDAP environment, the Identity System employs the3 component rule to perform the search. If the search is successful, theuser profile is recognized as a match—indicating that the usercorresponds to the test set (step 454). Otherwise, an unsuccessfulsearch yields a failed result—indicating that the user does notcorrespond to the test set (step 454).

In an alternate embodiment, a test filter is employed to determinewhether a user corresponds to a test set including at least one dynamicgroup (step 408, FIG. 9). This avoids the need to access DirectoryServer 36 when making the determination. The test filter maintains alocal copy of the user profile and compares the local copy to thematching criteria.

FIG. 12 is a flowchart describing an alternate embodiment of a processfor identifying dynamic groups corresponding to a user. Each step inFIG. 12 with the same reference number as a step in FIG. 9 operates inthe same manner as described above for the step in FIG. 9. In FIG. 12,the Identity System drills down into each initial test set to remove alldynamic groups from the initial test set that do not correspond to theuser (step 470). The Identity System performs this operation if the useris found to correspond to the initial test set in step 408. In drillingdown, the Identity System repeatedly partitions the initial test set andevaluates the partitions for matches to the user—employing the sameoperation described above for partitioning and evaluating correspondenceof the initially identified set of dynamic groups. The process shown inFIG. 12 allows multiple threads of operation to conceivably drill downinto multiple initial test sets—potentially increasing the speed ofidentifying dynamic groups that correspond to a user.

The foregoing detailed description of the invention has been presentedfor purposes of illustration and description. It is not intended to beexhaustive or to limit the invention to the precise form disclosed. Manymodifications and variations are possible in light of the aboveteaching. The described embodiments were chosen in order to best explainthe principles of the invention and its practical application to therebyenable others skilled in the art to best utilize the invention invarious embodiments and with various modifications as are suited to theparticular use contemplated. It is intended that the scope of theinvention be defined by the claims appended hereto.

1. A method of identifying dynamic groups corresponding to a user, themethod comprising: based on a rule that defines dynamic membership,partitioning, by a computer system, a set of dynamic groups includingdynamic members, into multiple test sets, wherein each test set in saidmultiple test sets includes at least one dynamic group from said set ofdynamic groups and wherein said set of dynamic groups are configured tohave the potential for said user to be a member, wherein said rule isstored in a dynamic rule attribute of an identity profile of said atleast one dynamic group, and wherein said at least one dynamic groupincludes one or more static members and an identification of each ofsaid static members is stored in a static member attribute for saididentity profile of said at least one dynamic group; selecting, by thecomputer system, a test set from the multiple test sets; storing anidentification of each of said dynamic members of said at least onedynamic group, wherein said identification of each of said dynamicmembers is stored in said static member attribute for said identityprofile of said at least one dynamic group; determining, by the computersystem, whether said identity profile corresponds to the selected testset in said multiple test sets, wherein said test set includes multipledynamic groups from said set of dynamic groups, wherein thedetermination of correspondence includes determining if said staticmember attributes within said identity profile meet the selected testset's filter requirements; and removing, by the computer system, theselected test set from the multiple test sets in response to the saidstatic member attributes within said identity profile not meeting theselected test set's filter requirements.
 2. A method according to claim1, wherein determining whether said user corresponds to a test set insaid multiple test sets comprises: setting matching criteria for saidtest set; and determining whether said user satisfies said matchingcriteria.
 3. A method according to claim 2, wherein each dynamic groupin said test set corresponds to at least a portion of said matchingcriteria.
 4. A method according to claim 2, wherein said matchingcriteria includes a logical OR of at least one filter from each dynamicgroup in said test set.
 5. A method according to claim 2, wherein saidmatching criteria is satisfied if a filter for any dynamic group in saidtest set is satisfied.
 6. A method according to claim 2, wherein: saidmatching criteria is a rule including a filter component, and saidfilter component is satisfied if any filter from a dynamic group in saidtest set is satisfied.
 7. A method according to claim 6, wherein saidfilter component is a logical OR of a filter from each dynamic group insaid test set.
 8. A method according to claim 6, wherein: said filtercomponent is a logical OR of a filter defining each dynamic group insaid test set.
 9. A method according to claim 6, wherein: said ruleincludes a searchbase component, and said searchbase componentcorresponds to a subtree containing said user.
 10. A method according toclaim 6, wherein: said rule includes a searchbase component, and saidsearchbase component corresponds to said user.
 11. A method according toclaim 10, wherein said user is represented by a user profile in adirectory.
 12. A method according to claim 11, wherein said determiningwhether said user satisfies said matching criteria comprises: searchingsaid directory using said rule.
 13. A method according to claim 12,wherein said directory is searched using a LDAP search.
 14. A methodaccording to claim 11, wherein said directory employs LDAP.
 15. A methodaccording to claim 14, wherein: said rule includes a scope component;and said scope component corresponds to a base object scope.
 16. Amethod according to claim 15, wherein said determining whether said usersatisfies said matching criteria comprises: searching said directoryusing said rule.
 17. A method according to claim 11, wherein saiddirectory is in communication with an Identity System.
 18. A methodaccording to claim 1, further comprising: eliminating all dynamic groupsin said test set from said set of dynamic groups, if it is determinedthat said user does not correspond to said test set.
 19. A methodaccording to claim 18, wherein said determining whether said usercorresponds to a test set in said multiple test sets and saideliminating all dynamic groups in said test set from said set of dynamicgroups are performed for each test set in said multiple test sets.
 20. Amethod according to claim 1, further comprising: removing from said testset all dynamic groups in said test set that do not correspond to saiduser, if it is determined that said user does correspond to said testset.
 21. A method according to claim 20, wherein said removing from saidtest set all dynamic groups in said test set that do not correspond tosaid user comprises: removing from said set of dynamic groups said alldynamic groups in said test set that do not correspond to said user. 22.A method according to claim 20, further comprising: eliminating alldynamic groups in said test set from said set of dynamic groups, if itis determined that said user does not correspond to said test set.
 23. Amethod according to claim 22, wherein said determining whether said usercorresponds to a test set in said multiple test sets, said removing fromsaid set of dynamic groups all dynamic groups in said test set that donot correspond to said user, and said eliminating all dynamic groups insaid test set from said set of dynamic groups, are performed for eachtest set in said multiple test sets.
 24. A method according to claim 1,wherein said determining whether said user corresponds to a test set insaid multiple test sets comprises: determining that all dynamic groupsin said test set do not correspond to said user, based on a singledirectory search.
 25. A method according to claim 1, wherein: saidmethod is performed as part of an Identity System.
 26. A methodaccording to claim 1, wherein: said method is performed as part of anAccess System.
 27. A method according to claim 1, wherein: said methodis performed as part of an integrated Access System and Identity System.28. A method according to claim 1, wherein determining whether said usercorresponds to a test set in said multiple test sets is performedwithout accessing a directory server.
 29. A method according to claim28, wherein said determining whether said user corresponds to a test setin said multiple test sets is performed using a filter tester.
 30. Amethod according to claim 1, wherein determining whether said usercorresponds to a test set in said multiple test sets is performed usingan SQL command.
 31. One or more processor readable storage deviceshaving processor readable code embodied on said one or more processorreadable storage devices, said processor readable code for programmingone or more processors and comprising: code for based on a rule thatdefines dynamic membership, partitioning, by a computer system, a set ofdynamic groups including dynamic members, into multiple test sets,wherein each test set in said multiple test sets includes at least onedynamic group from said set of dynamic groups and wherein said set ofdynamic groups are configured to have the potential for said user to bea member, wherein said rule is stored in a dynamic rule attribute of anidentity profile of said at least one dynamic group, and wherein said atleast one dynamic group includes one or more static members and anidentification of each of said static members is stored in a staticmember attribute for said identity profile of said at least one dynamicgroup; code for selecting, by the computer system, a test set from themultiple test sets; code for storing an identification of each of saiddynamic members of said at least one dynamic group, wherein saididentification of each of said dynamic members is stored in said staticmember attribute for said identity profile of said at least one dynamicgroup; code for determining, by the computer system, whether saididentity profile corresponds to the selected test set in said multipletest sets, wherein said test set includes multiple dynamic groups fromsaid set of dynamic groups, wherein the determination of correspondenceincludes determining if said static member attributes within saididentity profile meet the selected test set's filter requirements; andcode for removing, by the computer system, the selected test set fromthe multiple test sets in response to the said static member attributeswithin said identity profile not meeting the selected test set's filterrequirements.
 32. One or more processor readable storage devicesaccording to claim 31, wherein said code for determining whether a usercorresponds to a test set in said multiple test sets comprises: code forsetting matching criteria for said test set; and code for determiningwhether said user satisfies said matching criteria.
 33. One or moreprocessor readable storage devices according to claim 32, wherein: saidmatching criteria is a rule including a filter component, and saidfilter component is satisfied if a filter for any dynamic group in saidtest set is satisfied.
 34. One or more processor readable storagedevices according to claim 33, wherein: said rule includes a searchbasecomponent, and said searchbase component corresponds to said user. 35.One or more processor readable storage devices according to claim 34,wherein said user is represented by a user profile in a directory. 36.One or more processor readable storage devices according to claim 35,wherein said code for determining whether said user satisfies saidmatching criteria comprises: code for searching said directory usingsaid rule.
 37. One or more processor readable storage devices accordingto claim 36, wherein said code for searching said directory using saidrule comprises code for searching using a LDAP search.
 38. One or moreprocessor readable storage devices according to claim 35, wherein: saidrule includes a scope component, and said scope component corresponds toa base object scope.
 39. One or more processor readable storage devicesaccording to claim 38, wherein said code for determining whether saiduser satisfies said matching criteria comprises: code for searching saiddirectory using said rule.
 40. One or more processor readable storagedevices according to claim 31, wherein said processor readable codefurther comprises: code for eliminating all dynamic groups in said testset from said set of dynamic groups, if it is determined that said userdoes not correspond to said test set.
 41. One or more processor readablestorage devices according to claim 40, wherein said processor readablecode comprises, for each test set in said multiple test sets, code fordetermining whether said user corresponds to a test set in said multipletest sets and code for eliminating all dynamic groups in said test setfrom said set of dynamic groups.
 42. One or more processor readablestorage devices according to claim 31, wherein said processor readablecode further comprises: code for removing from said test set all dynamicgroups in said test set that do not correspond to said user, if it isdetermined that said user does correspond to said test set.
 43. One ormore processor readable storage devices according to claim 42, whereinsaid code for removing from said test set all dynamic groups in saidtest set that do not correspond to said user comprises: code forremoving from said set of dynamic groups said all dynamic groups in saidtest set that do not correspond to said user.
 44. One or more processorreadable storage devices according to claim 31, wherein said code fordetermining whether a user corresponds to a test set in said multipletest sets comprises: code for determining that all dynamic groups insaid test set do not correspond to said user, based on a singledirectory search.
 45. One or more processor readable storage devicesaccording to claim 31, wherein: said processor readable code isexecutable by an Identity System.
 46. One or more processor readablestorage devices according to claim 31, wherein: said processor readablecode is executable by an Access System.
 47. One or more processorreadable storage devices according to claim 31, wherein: said processorreadable code is executable by an integrated Access System and IdentitySystem.
 48. An apparatus, comprising: one or more storage devices; andone or more processors in communication with said one or more storagedevices, said one or more storage devices comprising processor readablecode for programming said one or more processors, said processorreadable code comprising: code for based on a rule that defines dynamicmembership, partitioning, by a computer system, a set of dynamic groupsincluding dynamic members, into multiple test sets, wherein each testset in said multiple test sets includes at least one dynamic group fromsaid set of dynamic groups and wherein said set of dynamic groups areconfigured to have the potential for said user to be a member, whereinsaid rule is stored in a dynamic rule attribute of an identity profileof said at least one dynamic group, and wherein said at least onedynamic group includes one or more static members and an identificationof each of said static members is stored in a static member attributefor said identity profile of said at least one dynamic group; code forselecting, by the computer system, a test set from the multiple testsets; code for storing an identification of each of said dynamic membersof said at least one dynamic group, wherein said identification of eachof said dynamic members is stored in said static member attribute forsaid identity profile of said at least one dynamic group; code fordetermining, by the computer system, whether said identity profilecorresponds to the selected test set in said multiple test sets, whereinsaid test set includes multiple dynamic groups from said set of dynamicgroups, wherein the determination of correspondence includes determiningif said static member attributes within said identity profile meet theselected test set's filter requirements; and code for removing, by thecomputer system, the selected test set from the multiple test sets inresponse to the said static member attributes within said identityprofile not meeting the selected test set's filter requirements.
 49. Anapparatus according to claim 48, wherein said code for determiningwhether a user corresponds to a test set in said multiple test setscomprises: code for setting matching criteria for said test set; andcode for determining whether said user satisfies said matching criteria.50. An apparatus according to claim 49, wherein: said matching criteriais a rule including a filter component, and said filter component issatisfied if a filter for any dynamic group in said test set issatisfied.
 51. An apparatus according to claim 50, wherein: said ruleincludes a searchbase component, and said searchbase componentcorresponds to said user.
 52. An apparatus according to claim 51,wherein said user is represented by a user profile in a directory. 53.An apparatus according to claim 52, wherein said code for determiningwhether said user satisfies said matching criteria comprises: code forsearching said directory using said rule.
 54. An apparatus according toclaim 52, wherein: said rule includes a scope component; and said scopecomponent corresponds to a base object scope.
 55. An apparatus accordingto claim 54, wherein said code for determining whether said usersatisfies said matching criteria comprises: code for searching saiddirectory using said rule.
 56. An apparatus according to claim 48,wherein said processor readable code further comprises: code foreliminating all dynamic groups in said test set from said set of dynamicgroups, if it is determined that said user does not correspond to saidtest set.
 57. An apparatus according to claim 48, wherein said processorreadable code further comprises: code for removing from said test setall dynamic groups in said test set that do not correspond to said user,if it is determined that said user does correspond to said test set; andcode for eliminating all dynamic groups in said test set from said setof dynamic groups, if it is determined that said user does notcorrespond to said test set.
 58. An apparatus according to claim 48,wherein said code for determining whether a user corresponds to a testset in said multiple test sets comprises: code for determining that alldynamic groups in said test set do not correspond to said user, based ona single directory search.
 59. An apparatus according to claim 48,wherein: said processor readable code is executable by an IdentitySystem.
 60. An apparatus according to claim 48, wherein: said processorreadable code is executable by an Access System.
 61. A method ofidentifying dynamic profiles corresponding to an entity, the methodcomprising: based on a rule that defines dynamic membership,partitioning, by a computer system, a set of dynamic groups includingdynamic members, into multiple test sets, wherein each test set in saidmultiple test sets includes at least one dynamic group from said set ofdynamic groups and wherein said set of dynamic groups are configured tohave the potential for said entity to be a member, wherein said rule isstored in a dynamic rule attribute of an identity profile of said atleast one dynamic group, and wherein said at least one dynamic groupincludes one or more static members and an identification of each ofsaid static members is stored in a static member attribute for saididentity profile of said at least one dynamic group; selecting, by thecomputer system, a test set from the multiple test sets; storing anidentification of each of said dynamic members of said at least onedynamic group, wherein said identification of each of said dynamicmembers is stored in said static member attribute for said identityprofile of said at least one dynamic group; determining, by the computersystem, whether said identity profile corresponds to the selected testset in said multiple test sets, wherein said test set includes multipledynamic groups from said set of dynamic groups, wherein thedetermination of correspondence includes determining if said staticmember attributes within said identity profile meet the selected testset's filter requirements; and removing, by the computer system, theselected test set from the multiple test sets in response to the saidstatic member attributes within said identity profile not meeting theselected test set's filter requirements.
 62. A method according to claim61, wherein said determining whether said entity corresponds to a testset in said multiple test sets comprises: setting matching criteria forsaid test set; and determining whether said entity satisfies saidmatching criteria.
 63. A method according to claim 62, wherein saidmatching criteria is satisfied if a filter for any dynamic profile insaid test set is satisfied.
 64. A method according to claim 62, wherein:said matching criteria is a rule including a filter component, and saidfilter component is satisfied if any filter from a dynamic group in saidtest set is satisfied.
 65. A method according to claim 64, wherein: saidrule includes a searchbase component; said searchbase componentcorresponds to said entity; said rule includes a scope component; andsaid scope component corresponds to a base object scope.
 66. A methodaccording to claim 65, wherein said entity is represented by a profilein a directory, wherein said determining whether said entity satisfiessaid matching criteria comprises: code for searching said directoryusing said rule.
 67. A method according to claim 61, wherein said entityis represented by a user profile and said set of dynamic profilesincludes dynamic group profiles.
 68. A method according to claim 61,further comprising: eliminating all dynamic profiles in said test setfrom said set of dynamic profiles, if it is determined that said entitydoes not correspond to said test set.
 69. A method according to claim61, wherein said determining whether said entity corresponds to a testset in said multiple test sets comprises: determining that all dynamicprofiles in said test set do not correspond to said entity, based on asingle directory search.
 70. One or more processor readable storagedevices having processor readable code embodied on said one or moreprocessor readable storage devices, said processor readable code forprogramming one or more processors and comprising: code for based on arule that defines dynamic membership, partitioning, by a computersystem, a set of dynamic groups including dynamic members, into multipletest sets, wherein each test set in said multiple test sets includes atleast one dynamic group from said set of dynamic groups and wherein saidset of dynamic groups are configured to have the potential for saidentity to be a member, wherein said rule is stored in a dynamic ruleattribute of an identity profile of said at least one dynamic group, andwherein said at least one dynamic group includes one or more staticmembers and an identification of each of said static members is storedin a static member attribute for said identity profile of said at leastone dynamic group; code for selecting, by the computer system, a testset from the multiple test sets; code for storing an identification ofeach of said dynamic members of said at least one dynamic group, whereinsaid identification of each of said dynamic members is stored in saidstatic member attribute for said identity profile of said at least onedynamic group; code for determining, by the computer system, whethersaid identity profile corresponds to the selected test set in saidmultiple test sets, wherein said test set includes multiple dynamicgroups from said set of dynamic groups, wherein the determination ofcorrespondence includes determining if said static member attributeswithin said identity profile meet the selected test set's filterrequirements; and code for removing, by the computer system, theselected test set from the multiple test sets in response to the saidstatic member attributes within said identity profile not meeting theselected test set's filter requirements.
 71. One or more processorreadable storage devices according to claim 70, wherein said code fordetermining whether said entity corresponds to a test set in saidmultiple test sets comprises: code for setting matching criteria forsaid test set; and code for determining whether said entity satisfiessaid matching criteria, wherein said matching criteria is satisfied if afilter for any dynamic profile in said test set is satisfied.
 72. One ormore processor readable storage devices according to claim 71, wherein:said matching criteria is a rule; said rule includes a filter component;said filter component is satisfied if a filter for any dynamic profilein said test set is satisfied; said rule includes a searchbasecomponent; said searchbase component corresponds to said entity; saidrule includes a scope component; and said scope component corresponds toa base object scope.
 73. One or more processor readable storage devicesaccording to claim 72, wherein said entity is represented by a profilein a directory, wherein said code for determining whether said entitysatisfies said matching criteria comprises: code for searching saiddirectory using said rule.
 74. One or more processor readable storagedevices according to claim 70, wherein said processor readable codefurther comprises: code for eliminating all dynamic profiles in saidtest set from said set of dynamic profiles, if it is determined thatsaid entity does not correspond to said test set.
 75. One or moreprocessor readable storage devices according to claim 70, wherein saidcode for determining whether said entity corresponds to a test set insaid multiple test sets comprises: code for determining that all dynamicprofiles in said test set do not correspond to said entity, based on asingle directory search.
 76. An apparatus, comprising: one or morestorage devices; and one or more processors in communication with saidone or more storage devices, said one or more storage devices comprisingprocessor readable code for programming said one or more processors,said processor readable code comprising: code for based on a rule thatdefines dynamic membership, partitioning, by a computer system, a set ofdynamic groups including dynamic members, into multiple test sets,wherein each test set in said multiple test sets includes at least onedynamic group from said set of dynamic groups and wherein said set ofdynamic groups are configured to have the potential for said entity tobe a member, wherein said rule is stored in a dynamic rule attribute ofan identity profile of said at least one dynamic group, and wherein saidat least one dynamic group includes one or more static members and anidentification of each of said static members is stored in a staticmember attribute for said identity profile of said at least one dynamicgroup; code for selecting, by the computer system, a test set from themultiple test sets; code for storing an identification of each of saiddynamic members of said at least one dynamic group, wherein saididentification of each of said dynamic members is stored in said staticmember attribute for said identity profile of said at least one dynamicgroup; code for determining, by the computer system, whether saididentity profile entity corresponds to the selected test set in saidmultiple test sets, wherein said test set includes multiple dynamicgroups from said set of dynamic groups, wherein the determination ofcorrespondence includes determining if said static member attributeswithin said identity profile meet the selected test set's filterrequirements; and code for removing, by the computer system, theselected test set from the multiple test sets in response to the saidstatic member attributes within said identity profile not meeting theselected test set's filter requirements.